@crgwbr : I love this, obviously, and want to move to React 19. But this is... pretty bold. Lot of things still not supporting React 19. Though it may be like react-helmet-async and they actually do just work fine.

Once tests pass I'll give it a go with my main project.

@silviogutierrez What would you think of getting rid of the helmet dependency entirely, in lieu of React 19's new metadata tag support? It'd involve some refactoring of how renderPage() works, but I think it'd be possible.

See https://react.dev/blog/2024/12/05/react-19#support-for-metadata-tags

Not opposed at all, I just have no idea how the tags are injected in the server side part. Given the app shell is rendered outside of React.

When 19 came out I scoured the docs and can't find a single reference. And yet it says it "works".

For the life of me, I cannot find a single example of how meta tags are "hoisted" on the server render. renderToString and its friends all return a strong that then goes inside your non-react-code app shell.

And yet the docs mention this works with SSR.

Maybe we have to move to this: https://react.dev/reference/react-dom/server/renderToReadableStream

@silviogutierrez Just pushed some prototype code for you to look at—native meta tag hoisting seems to work if we generate the app shell via React, rather than using string templating. The client side app still only rehydrates the part of the app within div#root. There's surely some bugs to workout here, but let me know your thoughts on the approach overall.

Ok good news and bad news.

Turns out those quote issues are unrelated, so ignore them. I marked the comment as complete.

Bad news: useId is unstable with this approach. React wants an exact document tree on the server and the client, otherwise they won't match. And useId is used all over the place in React. So you'll get rehydration issues.

Try it, in your app just call useId and render it server side and client side. You'll get a mismatch.

This is due to our architecture change of rendering a full document on the server and just a root node on the client.
save.patch

Attached is a POC patch that fixes the issue, but it comes at significant cost. We now have hydration on the client include the shell. So the shell needs to be aware of a lot of reactivated internals that the library consumer was not bothered with.

Note also in this crude approach we suppress some hydration stuff. But it's pretty gnarly.

Options:

1. Go back to react-helmet-async.
2. Figure out a way to expose the concept of the shell to the client with a consolidated API.
3. Encourage and move towards App or whatever being a full document that users now have to provide. But vite's code needs to be injected somehow.

I'm going to let this marinate and welcome your thoughts.

It does seem like React is very heavily encouraging full document handling, and all APIs are moving in that direction. So might be best to rip the bandaid.

Related issues (notably, HMR still works with the fix):

https://github.com/vercel/next.js/pull/31102/files
vitejs/vite-plugin-react#293
vitejs/vite-plugin-react#222

@crgwbr

Also I'm looking at this renderToPipeableStream

Seems like there are some parameters there that could be related and are meant for these situations. Maybe hydration takes them into account.